According to conventional business software terminology, a business object is an object model representing real-world items used during the transaction of business. For example, a business object may represent a business document such as a sales order, a purchase order, or an invoice. A business object may also represent items such as a product, a business partner, or a piece of equipment. Particular documents (e.g., SalesOrder SO435539) and/or items (e.g., ACME corporation) are represented by instances of their representing business object, or business object instances.
A business process platform provides application programming interfaces to allow read and write access to business object instances. Notably, each specific business object (i.e., object model) conforms to a same metadata model (or, “metamodel”). As a result, a business process platform may employ similar application programming interfaces, services, and persistencies to support all instances of each specific business object.
A business process platform may include other metamodels describing technical entities such as, but not limited to, a Web Service, a view, a floorplan (i.e., a user interface layout), a work center, UI texts, and process components. Each metamodel, including the business object metamodel, may in turn conform to a same meta-metamodel. More specifically, each metamodel may comprise an instance of a same meta-metadata model.
Some application development tools (e.g., Eclipse-based tools) operate based on specific metamodels (e.g., Eclipse Modeling Framework (EMF) models). These metamodels are instances of a specific meta-metamodel (e.g., eCore). As such, these tools are unable to utilize metamodels (and their instances) which conform to a different meta-metamodel. Moreover, application platforms which support the different meta-metamodel are unable to use metamodels (and their instances) which conform to the above-mentioned specific meta-metamodel.
In some cases, the native meta-metamodel (e.g., eCore) of a development tool exposes the same modeling unit types as another meta-metamodel (e.g., UML). Accordingly, desired metamodels of the other meta-metamodel may be directly mapped to metamodels of the native meta-metamodel for use by the development tool. Commonly-assigned U.S. patent application Ser. No. 12/690,511 describes systems to map between metamodels of meta-metamodels which exhibit different modeling unit types.
However, neither of the foregoing mapping techniques supports mapping between metamodels of a first meta-metamodel which supports specialization/inheritance on the metamodel level and metamodels of a second meta-metamodel which does not support specialization/inheritance on the metamodel level.